I’m seeing a major change in reported memory usage (and eventual termination due to memory pressure) when running a Core ML workload built with Xcode 27 on iOS/iPadOS 27.
The source code, model files, and MLModelConfiguration are unchanged. Only the Xcode/SDK version used to build the app differs.
On the same iPad running iPadOS 27:
Xcode 26 build: model loading and prediction complete normally, with a relatively small reported application footprint.
Xcode 27 build: the application footprint grows continuously as models are loaded and can exceed 5 GB. The app is eventually terminated unless models are unloaded very aggressively or the increased-memory-limit entitlement is used.
I also tested an Xcode 27 build on a device running iOS 26. Its reported peak was only around 300 MB. This suggests the change requires both an Xcode 27-linked binary and the iOS 27 runtime.
The workload consists of several compiled Core ML models using .cpuAndNeuralEngine. Loading models sequentially instead of concurrently does not materially change the final footprint. Releasing each MLModel after use does reduce it, so this appears to be model or Neural Engine residency being charged to the application rather than a conventional heap leak.
I noticed that the iOS 27 release notes mention Neural Engine memory now being attributed to the application instead of the system. However, I’m unclear about the practical consequences of that change.
If the same Neural Engine resources were already physically resident on iOS 26, I would have expected them to contribute to system memory pressure even when they were not attributed directly to the application. Instead, the older configuration runs comfortably, while the Xcode 27/iOS 27 combination approaches or crosses the application’s per-process memory limit.
A few additional observations:
The problem is more likely to occur after Core ML has already compiled and specialized the models. Cached model loading is much faster and the footprint grows quickly.
The first uncached run can survive model preparation because specialization spaces the loads farther apart.
Under Instruments, the app often does not terminate, presumably because profiling slows the workload enough to change the peak.
os_proc_available_memory() decreases in line with the newly reported footprint.
With the increased-memory-limit entitlement, the workload completes, but the reported footprint still reaches several gigabytes.
Has anyone else observed a large Core ML memory increase specifically with an Xcode 27 build running on iOS 27?
In particular, I’m trying to understand:
Is this purely a change in how existing Neural Engine memory is accounted for, or does the new runtime also retain or allocate more memory?
Is the new accounting used for the application’s jetsam/per-process memory limit?
Is this behavior intentionally gated by the linked SDK version? That would explain why an Xcode 26 build behaves differently on the same iOS 27 device.
Should applications now treat the Neural Engine residency of every loaded MLModel as part of their process-memory budget and unload models accordingly?
Are there recommended APIs or Core ML loading strategies for controlling this residency?
Any confirmation that others are seeing the same Xcode 27/iOS 27 behavior—or clarification of the intended memory-accounting model—would be very helpful.